There are many kinds of computer software, each with its own challenges and complexities. The invention described in this document is primarily for use in an area of software known as Enterprise Application Software. Enterprise software is characterized by the business functions that it automates—such as accounting, payroll, customer service, shipment tracking, supply chain, insurance, cost analysis, production planning, and more. Enterprise applications usually involve persistent data, lots of data, and many users accessing this data concurrently. Enterprise Application Software is organized within an architecture that represents the significant decisions about major components and how they interact. This architecture is known as an Enterprise Application Architecture.
A common way to describe an architecture is to decompose it into layers, and as such most discussions on enterprise architecture begin with an illustration in terms of layers. Furthermore, it is generally accepted that well-formed enterprise architectures consist of three principal layers: User Interface, Domain, and Data Source. The Domain layer (middle layer) is the focus of software development and contains object-oriented software known as business objects. Software developers design business objects with full consideration of the target platform, which includes, but is not limited to limitations in memory, CPU, networks, and databases. The collection of documents that describe the business objects in light of these limitations is known as the design model. It is well known that the design model isn't easily accessed by the User Interface, and likewise, it isn't easily persisted to a Data Source, especially in the case of relational databases. These difficult access points are known as representational gaps.
The three fundamental approaches for implementing design models that determine the extent of representational gaps are: top-down, bottom-up, and meet-in-the-middle. These approaches center around the flexibility of the relational database. The most common approach is bottom-up or meet-in-the middle because most enterprises have databases in production and databases can't be easily changed. The top-down approach is not often seen in production and is most suitable for embedded systems or application prototypes. The domain modeling approach chosen affects the representational gaps because of the bias in the direction of the approach. The top-down approach favors the conceptual model and results in complex database mappings from the design model to the database. The bottom-up approach favors the database and results in complex mappings between the user interface and the design model. The meet-in-the-middle approach tries to split the difference.
All of the aforementioned approaches have one thing in common; they implement a compromised design model. The demands of the user interface and the complexities of mapping to the database tug at the domain model causing undesirable changes. There are inevitable situations in which the purity of the object model must be compromised, such as for storage in a relational database. Whether you start at the top, bottom, or middle, there are compromising forces pulling the domain model in opposite directions. These forces seem to increase as complexity increases:    1) Increasing complexity makes it important to hide details from the users of the domain model. Hiding details using abstractions pulls the domain model towards the user interface. Therefore an original bottom-up design will be pulled towards the user interface as programmers build abstractions instead of complex mappings in the user interface.    2) Increasing complexity usually involves more database tables and complex relations resulting in a more normalized database. Therefore an original top-down design will be pulled towards the database as programmers encapsulate rich behavior with the database structure. Ultimately, this tug-of-war results in overly complicated user interfaces and overly complicated database mappings.